I only mentioned ExponentialBackOff because that is used in one of the recent changes related to retry (https://github.com/googleapis/google-auth-library-java/pull/1452/files)
I suppose you can do similar, by using HttpRequest's built-in retry handlers and set request.setNumberOfRetries(OAuth2Utils.DEFAULT_NUMBER_OF_RETRIES);? If you do not need ExponentialBackOff, maybe something simple e.g.

      // Set the number of retries
      request.setNumberOfRetries(OAuth2Utils.DEFAULT_NUMBER_OF_RETRIES); 
      // Retry on specific status codes (you might want to adjust these)
      request.setUnsuccessfulResponseHandler(
          new HttpUnsuccessfulResponseHandler() {
            @Override
            public boolean handleResponse(
                HttpRequest request, HttpResponse response, boolean supportsRetry)
                throws IOException   {
              return   RETRYABLE_STATUS_CODES.contains(response.getStatusCode());
            }
          });

About thread-safety, noticed HttpRequest is also marked as not safe here, likely because its member variable hold state information . But I don't see it a concern in this implementation, as executeAsync() is not used and getS2AConfigFromMDS() creates and executes a request each time.

I am leaning toward switching to HttpRequest's built-in retry handlers, logic like to customize the retry behavior based on return code can go into HttpUnsuccessfulResponseHandler. See other comment for details.

Can you add this explanation as javadoc comment here or to getS2AConfigFromMDS() for future references?

S2AConfig.createBuilder().build() sets plainTextAddress and mtlsS2AAddress to "" by default. Can we move this code in this try block into the one below (merging them)?

Done in ed681f5

nit: Can this be 200? Or are there other 2xx/ 3xx codes?

Yeah it can just be 200. We expect only 200 on successful responses. Done in 20825f7

nit: Can these values be stored as a map?

perhaps Map<String, String> s2aContentMap (or a different name)? there would be one setter setS2AContentMap() instead of 4?

Done in 594df7b

Ah, I was going to suggest something like:
For valid data:

transportFactory.transport.setS2AContentMap(
  ImmutableMap.of(S2A.S2A_PLAINTEXT_ADDRESS_JSON_KEY, S2A_PLAINTEXT_ADDRESS,
                  S2A.S2A_MTLS_ADDRESS_JSON_KEY, S2A_MTLS_ADDRESS));

For invalid data:

transportFactory.transport.setS2AContentMap(
  ImmutableMap.of(INVALID_JSON_KEY, S2A_PLAINTEXT_ADDRESS,
                  S2A.S2A_MTLS_ADDRESS_JSON_KEY, S2A_MTLS_ADDRESS));

And the content would be populated via iteration through tkey k/v's of the map. Something like:

if (requestStatusCode == 200) {
  for (Map.Entry<String, String> entrySet: content.entrySet()) {
    content.put(entrySet.getKey(), entrySet.getValue())
  }
}

This is more succinct -- thanks. Done in 1e6c058

I'd like Javadocs for all these public things, pointing to public docs for MDS.

We don't have this documented in public MDS docs (e.g. https://cloud.google.com/compute/docs/metadata/predefined-metadata-keys). We do have an AIP: https://google.aip.dev/auth/4115 which discusses this autconfig endpoint and how it fits in the mTLS via S2A + bound tokens story. WDYT about 934679c?

Can you add comment on why these are ignored?

I added a comment in 6644d50. In general, if there is any error in this function, we ignore, and populate empty addresses in the S2AConfig.

maybe do try/catch block around these to be more specific about the exceptions catching? Nested try/catch blocks are a bit hard to read.

Ah, I think I was the one that suggested this, but am open to having the try-catch blocks be more specific or a different implementation.

I suggested just have one try-catch block since this code doesn't catch or return the error message back to the user. It just catches any IO error and returns an empty S2AConfig back. Unfortunately, this doesn't provide any useful feedback to the user. Given that this is how it behaves already in Go, I thought it would just be simpler to have a catch-all (one big try block) for this logic.

Ideally, we would have more specific try-catch blocks which could tell the user exactly what went wrong (i.e. failed to build the request because x, or the request failed because of y).

I believe there are two spots where we potentially would need to add try-catches:

1. parseAs (Ah, thanks for the correction below)
2. request.execute()

There are a few places in this block that throw an IOException (the parseAs and buildGetRequest also throw IOException), so I removed the current nested try/catch block structure and added two separate try/catch blocks around the lines that throw an exception. Because we are getting rid of the big block, I also moved around variable definitions closer to where they are used.

6644d50

@lqiu96 , I think my changes and your comment happened at same time. Reading through your comment, the changes I just push match your suggestion. I removed the big try/catch and just did 2 smaller ones around building the request and executing it.

@zhumin8 , @lqiu96: I am fine with either option -- let me know if you prefer reverting to the 1 big/try catch block, or if you prefer the current state which has no nesting, but a few smaller try/catch blocks

I am fine with splitting it up to reduce nesting.